Polizei und Geheimdienste in Deutschland haben mittlerweile eine ganze Reihe an Staatstrojanern, um Geräte von Verdächtigen und Zielpersonen zu hacken und zu überwachen. Neben kommerzieller Spionage-Software nutzt das Bundeskriminalamt auch einen selbst programmierten Staatstrojaner: die „Remote Communication Interception Software“ (RCIS).

Mit einer ersten Version kann die Polizei seit 2016 Skype auf Windows abhören, eine zweite Version infiltriert seit 2018 auch mobile Geräte wie Smartphones. Um den gesetzlichen Vorgaben zu entsprechen, hat das BKA eine Art Pflichtenheft verfasst und den Trojaner vom Bundesamt für Sicherheit in der Informationstechnik und der Firma TÜV Informationstechnik überprüfen lassen. Auch die Bundesbeauftragten für Datenschutz haben den BKA-Trojaner RCIS kontrolliert.

Wir haben diesen Prüfbericht per Informationsfreiheits-Anfrage auf FragDenStaat erhalten und veröffentlichen ihn an dieser Stelle als PDF und Volltext.

Vier Jahre programmieren, vier Jahre prüfen

Laut Informatiker:innen sind Staatstrojaner mit Gesetzen nicht kontrollierbar. Kommerziellen Staatstrojaner-Firmen wie FinFisher und NSO Pegasus wird immer wieder vorgeworfen, Menschenrechte zu verletzen und Gesetze zu brechen. Kontrollen offenbaren wiederholt drastische Missstände.

Das Bundeskriminalamt durfte einen Trojaner von FinFisher fünf Jahre lang nicht einsetzen, weil sein Funktionsumfang gegen Recht und Gesetz verstieß. Bei NSO Pegasus hatte das BKA zwei Jahre lang „gravierende rechtliche Bedenken“. DigiTask verstieß so deutlich gegen deutsche Gesetze, dass die Software nach der ersten unabhängigen Untersuchung eingestampft wurde.

Das zeigt, wie wichtig es ist, auch die BKA-eigene Software gründlich zu kontrollieren. Die Untersuchung des Bundesdatenschutzbeauftragten wird dem jedoch nicht gerecht.

Das BKA hat RCIS vier Jahre lang programmiert, der Datenschutzbeauftragte hat den Trojaner nochmal vier Jahre lang geprüft. Sein Bericht hat erhebliche Leerstellen und umfasst lediglich zehn Seiten. Zum Vergleich: Sein Kontrollbericht zu Sicherheitsüberprüfungen beim Bundesamt für Bevölkerungsschutz und Katastrophenhilfe hat 23 Seiten.

Der Chaos Computer Club hatte den DigiTask-Trojaner analysiert und dafür einmal 20 und nochmal 17 Seiten Bericht sowie diverse Anhänge veröffentlicht.

Zehn Seiten Ergebnis, große Teile geschwärzt

Von diesen zehn Seiten hat das BKA im Zuge unserer Anfrage große Teile geschwärzt, weil sie die Sicherheit der Bundesrepublik gefährden. Den ungeschwärzten Bericht darf die Öffentlichkeit erst im Jahr 2080 lesen. Bis dahin sieht das so aus:

Fundamentale Probleme nicht geprüft

Die Behörde von Ulrich Kelber ist zuständig für den Datenschutz und die Informationsfreiheit, aber nicht für andere Bereiche. Die größten Probleme von Staatstrojanern darf er also gar nicht untersuchen.

Staatstrojaner schwächen die IT-Sicherheit aller, weil sie Sicherheitslücken ausnutzen und offenlassen, statt sie zu schließen. Das BKA hat bereits zugegeben, genau das zu tun. Der Datenschutzbeauftragte erwähnt das Problem in Interviews und Stellungnahmen, aber nicht im Prüfbericht.

Staatstrojaner sind verfassungsrechtlich so sensibel, dass das Bundesverfassungsgericht in einem Urteil dafür extra ein neues Grundrecht formuliert hat: das Grundrecht auf Gewährleistung der Vertraulichkeit und Integrität informationstechnischer Systeme. Der Staat muss dieses Recht nicht nur achten, sondern aktiv gewährleisten.

Staatliches Hacken tut das Gegenteil, es bricht Vertraulichkeit und Integrität der Zielgeräte. Das ist laut Bundesverfassungsgericht nur in engen Grenzen erlaubt, zum Beispiel um konkret bevorstehende Terroranschläge zu verhindern. Mittlerweile setzen Polizeien Staatstrojaner jedoch auch bei Alltagskriminalität ein, vor allem gegen Drogen. Dazu schweigt der Prüfbericht ebenfalls.

Auch die Daten, die ein Staatstrojaner von einem infizierten Zielgerät ausleitet, sind weder vertraulich noch integer. Der Staat erlangt ja nicht die vollständige Hoheit über das System, sondern Nutzer:innen, installierte Software und Apps sowie andere Angreifer:innen tummeln sich ebenfalls darauf. Sämtliche Daten, die der Trojaner an Polizei oder Geheimdienste übermittelt, können von allen Akteur:innen manipuliert oder gefälscht werden.

Dieses Problem hat der Chaos Computer Club bereits praktisch demonstriert und dem DigiTask-Trojaner falsche Screenshots untergeschoben. Auch dazu verliert der Bericht kein Wort.

Verbotenes bitte wieder löschen

Moderne IT-Geräte sind mindestens ausgelagerte Gehirne, mittlerweile wissen sie teilweise mehr über uns als wir selbst. Wer sich heimlich in diese Geräte hackt, dringt damit in den Kernbereich privater Lebensgestaltung ein. Dieser „letzte unantastbare Bereich menschlicher Freiheit“ ist laut Bundesverfassungsgericht „der Einwirkung der gesamten öffentlichen Gewalt entzogen“. Der Staat darf unter keinen Umständen eingreifen.

Im Bericht kritisiert der Datenschutzbeauftragte nicht, dass Staatstrojaner in diesen Kernbereich eindringen. Kelber „[weist] in diesem Zusammenhang aber darauf hin, dass aufgezeichnete Gespräche auch teilweise gelöscht werden können müssen, sofern der Schutz des Kernbereichs privater Lebensgestaltung dies erfordert.“ Dass solche Informationen gar nicht erst erhoben werden dürfen, sagt er nicht.

Stichproben im Quelltext

Die beiden Mitarbeiter des Datenschutzbeauftragten konnten zwar den Quellcode der Software einsehen, was sie bei kommerziellen Staatstrojanern oft nicht dürfen. Die Prüfer haben aber nicht den vollständigen Quelltext systematisch analysiert, sondern lediglich „stichprobenartige Einsicht in den Quellcode“ genommen.

Die Prüfer wissen, dass man die Rechtmäßigkeit der Software eigentlich nicht beweisen kann – selbst mit dem vollständigen Quellcode: „Der Nachweis, ob eine Software nicht geforderte bzw. über das Zulässige hinaus gehende Funktionen aufweist, ist allerdings praktisch kaum zu führen.“ Warum der Datenschutzbeauftragte dann nicht wenigstens alles prüft, sondern sich auf Stichproben beschränkt – das wird nicht erklärt.

Darüber hinaus haben die Prüfer „Anwendungstests“ durchgeführt und getestet, ob die Überwachung endet, wenn die Netzwerkverbindung getrennt oder der Trojaner aus der Ferne gelöscht wird.

Keine offizielle Beanstandung

Das Fazit dieser Überprüfung ist alles andere als ein Gütesiegel. Im Jahresbericht schreibt der Datenschutzbeauftragte: „Das BKA hat die datenschutzrechtlichen Anforderungen zur Nachvollziehbarkeit […] verbessert.“ Im Bericht schreibt er jedoch: „Ich empfehle, die Software noch besser kontrollierbar zu gestalten.“

Als „wesentliches Ergebnis“ nennt Kelber: „Die datenschutzrechtliche Kontrolle der Software ███████ führt zu keiner Beanstandung.“ Eine offizielle Beanstandung ist das schärfste Mittel des Datenschutzbeauftragten gegenüber anderen Behörden, das er im fraglichen Jahr nur drei Mal anwendete.

CCC bietet richtige Prüfung

Thorsten Schröder hat bereits mehrere Staatstrojaner für den Chaos Computer Club analysiert. Den Prüfbericht des Datenschutzbeauftragten kommentiert der Hacker: „Dieser Bericht enttäuscht. Die Datenschutzbehörde untersucht einen kleinen Teil relevanter Fragen in einem Ausschnitt des Staatstrojaners, und die Öffentlichkeit darf lediglich Auszüge des Befunds lesen. Das Ergebnis von vier Jahren Arbeit sind zehn Seiten weitreichend geschwärztes Papier ohne Details. Eine effektive Kontrolle dieser hochsensiblen Schadsoftware findet augenscheinlich nicht statt.“

Der Chaos Computer Club bietet an, den Staatstrojaner nochmal kompetent und umfassend zu prüfen. CCC-Sprecher Linus Neumann erklärt: „Innenminister und BKA haben immer wieder Behauptungen über Staatstrojaner aufgestellt, die sich bei genauerer Betrachtung als unwahr herausgestellt haben. Die einzige seriöse Kontrolle des staatlichen Hackens hat der CCC geleistet. Sehr gerne prüfen wir auch die vom BKA programmierte Software. Wir freuen uns auf die neue Offenheit der Ampel-Regierung.“

---

Diese Recherche ist ein Langzeit-Projekt. Im Februar 2016 gibt das BKA den selbst programmierten Staatstrojaner „RCIS“ für den Einsatz frei. Im Mai 2016 kündigt die damalige Bundesdatenschutzbeauftragte Andrea Voßhoff eine Kontrolle beim BKA an, wir veröffentlichen an dieser Stelle die Ankündigung. Im Juli 2017, April 2018 und Juni 2018 beantragen wir Akteneinsicht. Die wird jedes Mal abgelehnt, weil der Vorgang noch läuft. Im Mai 2019 prüfen die Beamten den BKA-Trojaner nochmal. Im Juni 2020 beschreibt der Datenschutzbeauftragte Ulrich Kelber die Prüfung in seinem Jahresbericht. Am selben Tag beantragen wir den Prüfbericht erneut. Ein Jahr später haben wir immer noch keine Antwort und drohen, den Informationsfreiheits-Beauftragten wegen Untätigkeit zu verklagen. Im Januar 2022 erhalten wir das Dokument – anderthalb Jahre nach unserer Anfrage und fünfeinhalb Jahre nach Beginn der Prüfung. Demnächst bekommen wir dafür eine Rechnung.

---

Hier das Dokument in Volltext:

---

• Datum: 25. Juni 2020
• Einstufung: GEHEIM amtlich geheimhalten, Die VS-Einstufung endet mit Ablauf des Jahres 2080, Mit Schwärzung offen
• Von: Bundesbeauftragter für den Datenschutz und die Informationsfreiheit, Ulrich Kelber
• An: Bundeskriminalamt, Präsident, Holger Münch, Thaerstraße 11, 65193 Wiesbaden
• Kopie: Bundesministerium des Innern, ÖS I 3, Kai Schollendorf, Alt-Moabit 140, 10557 Berlin
• Geschäftszeichen: 32-642/054#1001

Quellen-TKÜ beim Bundeskriminalamt (BKA)

Beratungs- und Kontrollbesuch

Sehr geehrter Herr Präsident,

vom 14.05.2019 bis 15.05.2019 haben meine Mitarbeiter Herr RD Kugelmeier und Herr RD Bergemann einen Beratungs- und Kontrollbesuch beim BKA in ███████ ███████ zur vom BKA selbst entwickelten Software für die sogenannte Quellen-Telekommunikationsüberwachung „Remote Communication Interception Software (RCIS)“ █████████████████████ durchgeführt. Bereits zuvor war vom 29.08.2016 bis 31.08.2016 ein Besuch durchgeführt worden, dessen Erkenntnisse in diesen Bericht einfließen. Die Mitarbeiterinnen und Mitarbeiter der Referate und des behördlichen Datenschutzbeauftragten haben das BKA bei dem Besuch vertreten.

Für die freundliche Aufnahme meiner Mitarbeiter und die erwiesene Kooperationsbereitschaft während des Besuchs danke ich. Ich bitte nochmals um Verständnis für die späte Absendung des Berichts.

1. Wesentliches Ergebnis:

Die datenschutzrechtliche Kontrolle der Software ███████ führt zu keiner Beanstandung.

• Die technische Prüfung hat keine Anhaltspunkte dafür ergeben, dass die Software außer der laufenden Telekommunikation weitere Daten erhebt.
• Der Quellcode der Software zur Quellen-Telekommunikationsüberwachung (Quellen-TKÜ) hat sich als gut dokumentiert ergeben und das BKA war in der Lage, den Entwicklungsprozess gut nachvollziehbar darzustellen.
• Anwendungstests haben ergeben, dass die Software bei Beenden der Telekommunikationsverbindung die Überwachung automatisch abbricht. Unter Testbedingungen war diese also weitgehend auf die laufende Telekommunikation beschränkt.
• Ich empfehle, die Software noch besser kontrollierbar zu gestalten. Um dies zu erreichen, sollte der Schwerpunkt stärker darauf gelegt werden, über alle Entwicklungsschritte hinweg nachverfolgbar zu machen, ob die aufgrund rechtlicher Vorgaben formulierten technischen Anforderungen bis in die Ebene des Quellcodes umgesetzt wurden. So könnte beispielsweise der Quellcode innerhalb der Versionsverwaltung zu einzelnen Testcases und dieser wiederum zu den Softwareanforderungen konsequent referenziert werden. Damit würde noch besser nachverfolgbar, ob die Anforderungen sich im Quellcode selbst niederschlagen. Dabei kann auch eine bessere Toolunterstützung durch einen höheren Grad der Automatisierung dienlich sein.

2. Im Einzelnen:

2.1 Sachverhalt

2.1.1 Allgemeine Feststellungen und festgelegter Funktionsumfang RCIS

Gegenstand des Beratungs- und Kontrollbesuchs war die vom BKA selbst entwickelte Software für die Quellen-TKÜ. Gegenstand war die Software ██████████████ █████████████████████████████████████████████████. Weitere Versionen der Software – ███████████████████████████████████ ██████████████ sind nicht Gegenstand dieses Berichts und werden in weiteren datenschutzrechtlichen Kontrollen untersucht werden.

Die Software ist geeignet, ███████████████████████████████████ ██████████████████████████████████████████████████████████████ ██████████████████████████████████████████████████████████████ ██████████████████████████████████████████████████████████████ ██████████████████████████████████████████████████████████████ ██████████████████████████████████████████████████████████████ ████████████████████████████████████████████

Die Software ist in der Lage, ████████████████████████████████ ██████████████████████████████████████████████████████████████ ██████████████████████████████████████████████████████████████ ██████████████████████████████████████████████████████████████ ██████████████████████████████████████████████████████████████ █████████████████████████████████████████████████████████

██████████████████████████████████████████████████████████████ ██████████████████████████████████████████████████████████████ ██████████████████████████████████████████████████████████████ ████████████████████████████████████████████████

Die Software ist in ein ██████████████████████████████████████ ██████████████████████████████████████████████████████████████ ██████████████████████████████████████████████████████████████ ██████████████████████████████████████████████████████████████ ██████████████████████████████████████████████████████████████ ██████████████████████████████████████████████████████████████ ██████████████████████████████████████████████████████████████ ███████████████████████████████████████████████████████

2.1.2 Quellcode und Dokumentation

Die Anforderungen an die Software hatten BMI und BKA in der Standardisierten Leistungsbeschreibung (SLB) definiert. Zur ersten Version der SLB hatte ich insbesondere mit Schreiben vom 29.08.2012 und vom 03.09.2012 Stellung genommen (V-620/057#0146), zu der aktualisierten Version mit Schreiben vom 15.01.2019.

Das Anforderungsmanagement verwendet als ████████████████████████████ ███████. Die Architekturdokumentation und -modellierung erfolgt in dem ███████ █████████████████████████████████████████████████. Der ███████ ███████████████████████████████████ verwaltet und ██████████████ entwickelt. Die Test- und Releaseumgebungen ███████████████████████████████████.

Die Netzwerke sind █████████████████████████████████████████████████. Dies hat Auswirkungen auf ████████████████████████████. Zum einen ist ███████ ███████████████████████████████████ notwendig. Dies äußert sich etwa darin, dass ██████████████████████████████████████████ sind. Zum anderen ███████ █████████████████████████████████████████████████. Denn hier ist es ███████ ███████. Während des Kontrollbesuchs konnte das BKA ███████ ██████████████████████████████████████████████████████████████ ████████████████████████████████.

Ein ███████████████████████████████████. Die Anforderungen sind ███████ ██████████████ festgelegt. Dort sind sowohl die gesetzlichen Anforderungen formuliert als auch durch die Anwendungsebene die polizeilich-taktischen Bedürfnisse vorgegeben. Aus der Gesamtheit dieser funktionalen und nicht funktionalen Anforderungen wird ein Architekturmodell erzeugt. Hierzu wird █████████████████████ ██████████████. Das Ergebnis ██████████████████████████████████████████ █████████████████████.

Die weitere Nachverfolgung von Anforderungen und Designvorgaben ███████ ███████████████████████████████████████████████████████, welches das BKA ██████████████ einsetzt.

2.1.3 Externe Prüfungen

Die neue Software wurde vom BKA selbst vielfach getestet und verschiedenen Prüfungen unterworfen. Als externer Dienstleister hat █████████████████████ █████████████████████. Die dabei erstellten Unterlagen habe ich ergänzend durchgesehen.

Der Bericht ██████████████, bezieht sich auf die Version ███████████████████████████████████.

2.1.4 Testanwendungen

██████████████████████████████████████████████████████████████ ██████████████████████████████████████████████████████████████ ██████████████████████████████████████████████████████████████ █████████████████

Es wurden mehrere ██████████████████████████████████████████ █████████████████████. Dabei wurden auch die Netzwerkverbindungen ██ ███████████████████████████████████ getrennt. Beim ██████████████ █████████████████████ konnte ich mich davon überzeugen, dass die Aufzeichnung der █████████████████████ unmittelbar beendet wird. Bei ███ ██████████████████████████████████████████████████████████████ ██████████████████████████████████████████████████████████████ ██████████████ Trennung der Netzwerkverbindung ██████████████ ███████████████████████████████████. Dies bedeutet, dass ███████ ██████████████████████████████████████████

Es wurde darüber hinaus eine Fernlöschung der Quellen-TKÜ Software durchgeführt und danach █████████████████████. Es erfolgte erwartungsgemäß keine Aufzeichnung ██████████████.

██████████████████████████████████████████████████████████████ ██████████████████████████████████████████████████████████████ ██████████████████████████████████████████████████████████████ ██████████████████████████████████████

2.2 Bewertung

Die datenschutzrechtliche Bewertung beschränkt sich in diesem Bericht auf eine technische Prüfung. █████████████████████████████████████ ██████████████████████████████████████████████████████████████ ███████████████████████████████████████████.

Software zur Quellen-TKÜ ist strukturell in grundrechtlicher Hinsicht besonders eingriffsintensiv. Leitgedanke des datenschutzrechtlichen Kontrollbesuchs war deshalb insbesondere die Frage, ob sich die technische Funktionalität von der abstrakten Anforderungsebene bis zur Realisierung transparent nachvollziehen und prüfen lässt.

Ein besonderes Augenmerk war dabei darauf gerichtet, ob die Software über die reine Quellen-TKÜ hinausgehende Funktionalitäten aufweist und die gesetzlich vorgeschriebenen technischen Sicherungen enthält. Der Nachweis, ob eine Software nicht geforderte bzw. über das Zulässige hinaus gehende Funktionen aufweist, ist allerdings praktisch kaum zu führen. Eine Kontrolle kann insofern immer nur eine Annäherung und Stichprobe sein. Diese wurde vorliegend durch Sichtung der Anforderungs- und Dokumentationslage, durch Sichtung des Berichts ██████████████ und durch eine stichprobenartige Einsicht in den Quellcode selbst durchgeführt.

Besondere Herausforderungen sind insbesondere durch die Arbeit in einem größeren Entwicklerteam vorhanden. Dies wird verstärkt durch die gleichzeitig sehr streng auszulegenden Anforderungen. Gleichwohl hat sich insbesondere der Quellcode als gut dokumentiert ergeben und das BKA war in der Lage, den Prozess gut nachvollziehbar darzustellen.

Anwendungstests haben ergeben, dass die Software bei Beenden der Telekommunikationsverbindung die Überwachung automatisch abbricht. Unter Testbedingungen war diese also auf die laufende Telekommunikation beschränkt.

██████████████████████████████████████████████████████████████ ████████████████████████████

2.2.1 Zulässiger Funktionsumfang und festgelegte Maßstäbe

Der zulässige Funktionsumfang der Software ergibt sich aus § 20l BKAG alt sowie aus dem neugefassten § 100a StPO. Diese Vorschriften werden durch die Standardisierte Leistungsbeschreibung (SLB) konkretisiert.

Für die Quellen-TKÜ ist in Abgrenzung zur sog. Online-Durchsuchung sicherzustellen, die Überwachung auf die laufende Telekommunikation zu beschränken. Der Eingriff in das informationstechnische System muss notwendig sein, um die Überwachung und Aufzeichnung der Telekommunikation insbesondere trotz der Verschlüsselung der Kommunikation zu ermöglichen. Die Anforderungen an die technische Sicherheit sind im Übrigen dieselben, wie im Falle der sog. Online-Durchsuchung.

Für diese bestimmt § 20k BKAG-alt, dass

• an dem informationstechnischen System nur Veränderungen vorgenommen werden, die für die Datenerhebung unerlässlich sind,
• die technisch vorgenommenen Veränderungen bei Beendigung der Maßnahme soweit technisch möglich automatisiert rückgängig gemacht werden,
• eingesetzte Mittel nach dem Stand der Technik gegen Veränderung, unbefugte Löschung und unbefugte Kenntnisnahme geschützt sind und
• jeder Einsatz des technischen Mittels protokolliert wird.

Diese Vorgaben muss RCIS einhalten. Dies ist durch technische und organisatorische Maßnahmen sicherzustellen. Dies lässt sich nur dann sicher beurteilen, wenn über den gesamten Entwicklungsprozess nachvollziehbare Maßstäbe festgelegt und eingehalten sind.

Auf der ersten Stufe sind die gesetzlichen Vorgaben in der SLB konkretisiert. Eine Ebene tiefer finden sich die weiteren Festschreibungen in den technischen Unterlagen.

2.2.2 Externe Prüfungen

Aus dem Bericht ██████████████████████████████████████████████ ██████████████████████████████████████████████████████████████ ██████████████████████████████████████████████████████████████ ██████████████████████████████████████████████████████████████ ██████████████████████████████████████████████████████████████ ██████████████████████████████████████████████████████████████ ██████████████████████████████████████████████████████████████ ██████████████████████████████████████████████████████████████ ██████████████████████████████████████████████████████████████ ██████████████████████████████████████████████████████████████ ██████████████████████████████████████████████████████████████ ███████████████████

2.2.3 Quellcode und Dokumentation

2.2.3.1 Allgemeine Anmerkungen

Die besondere Herausforderung für das BKA besteht hier darin, den komplexen Entwicklungsprozess auf allen Ebenen korrekt darzustellen und zu dokumentieren. Er betrifft nämlich auf der obersten Ebene die Grundstruktur und Architektur der Software – quasi die „tragenden Bauteile“ -, auf einer weiteren Ebene die Hauptfunktionen und schließlich auf den unteren Ebenen untergeordnete Funktionalitäten, aus denen sich die Software im Detail zusammensetzt. Im Ergebnis muss die Software auf allen Ebenen überprüfbar sein. Auch auf den „unteren“ Ebenen können die Funktionalitäten die Software und wesentliche Funktionen beeinflussen. Deshalb muss ihre Integration in den Gesamtkontext der Software nachvollziehbar und dokumentiert sein. Softwareentwicklung erfordert also Feedbackschleifen, hinsichtlich der Realisierung des konkreten Softwaredesigns und der Gewährleistung der Funktionalität von der Entwicklung einzelner Progammteile bzw. Funktionen bis zur Ebene der Architektur und Anforderungen.

██████████████████████████████████████████████████████████████ ██████████████████████████████████████████████████████████████ ██████████████████████████████████████████████████████████████ ██████████████████ Die Herausforderung in einer Kontrolle ist insbesondere, eine saubere Verbindung der Dokumentationen einerseits auf der Anforderungs- und Architekturebene und andererseits der Entwicklungsebene sicherzustellen. ███████ ██████████████████████████████████████████████████████████████ ██████████████████████████████████████████████████████████████ ██████████████████████████████████████████████████████████████ ██████████████████████████████████████████████████████████████ ██████████████████████████████████████████████████████████████ ██████████████████████████████████████████████████████████████ ███████████████

2.2.3.2. Geprüfte Szenarien

Während des Besuchs haben meine Mitarbeiter Szenarien vorgegeben, mit denen die durchgängig nachvollziehbare Dokumentation geprüft werden sollte. Dazu haben diese auszugsweise einige Funktionalitäten herausgegriffen, um deren Standort sowohl im Quellcode als auch im Anforderungsmanagement nachzuvollziehen. Im Ergebnis hat das BKA die durchgängige Nachvollziehbarkeit darlegen und demonstrieren können.

Diese auszugsweise angesehenen Funktionalitäten waren

• Löschfunktion: Auf welche Weise wird die Software auf dem Zielsystem sauber gelöscht
• Beginn der Telekommunikation ██████████████
• Versendung einer Datei

Die Löschfunktion ist wie oben dargelegt eine der rechtlichen Anforderungen des § 20 BKAG-alt. Diese wird entsprechend in der SLB gefordert. Anhand der Dokumentation des Quellcodes konnte ich die entsprechenden Passagen des Quellcodes zu dieser Funktion identifizieren und ansehen. █████████████████████ ██████████████████████████████████████████████████████████████ ██████████████████████████████████████████████████████████████ ██████████████████████████████████████████████████████████████ ██████████████████████████████████████████████████████████████ ██████████████████████████████████████████████████████████████ ██████████████████████████████████████████████████████████████ █████████████████ Bei dieser Gelegenheit konnte ich auch Einsicht in weitere Funktionalitäten der Software nehmen, die durch die Löschfunktion „rückgängig“ gemacht werden. ████████████████████████████████████████████████████ █████████████████████████████████████████████████████████ Dabei waren keine Defizite in der Dokumentation des Quellcodes oder unzulässige Funktionalitäten erkennbar. Im Ergebnis konnte ich den Quellcode und seine Dokumentation sowie den Ausführungspfad der Löschfunktion nachvollziehen.

Vereinzelt habe ich anhand stichprobenartiger Code-Bestandteile nach deren Rechtfertigung in den Anforderungen gesucht. Dieses Vorgehen entspricht der umgekehrten Blickrichtung von dem realisierten Code zurück zur Gesamtheit der Anforderungen. Dabei soll nachgewiesen werden, dass nicht mehr und nicht undokumentiert Softwarefunktionalität erstellt wurde als ursprünglich gefordert. ██████████████ ██████████████████████████████████████████████████████████████ ██████████████████████████████████████████████████████████████ ██████████████████████████████████████████████████████████████ ██████████████████████████████████████████████████████████████ ██████████████████████████████████████████████████████████████ ██████████████████████████████████████████████████████████████ ██████████████████████████████████████████████████████████████ ██████████████████████████████████████████████

Das zweite Szenario untersuchte, █████████████████████████████ ██████████████████████████████████████████████████████████████ ██████████████████████████████████████████████████████████████ ██████████████████████████████████████████████████████████████ ██████████████████████████████████████████████████████████████ ██████████████████████████████████████████████████████████████ ██████████████████████████████████████████████████████████████ ███████████████████████████████. Im Ergebnis konnte ich die Wirkweise der gewählten Softwarelösung sowie die Einhaltung der rechtlichen Rahmenbedingungen nachvollziehen.

Das dritte Szenario behandelte ███████████████████████████████ ██████████████████████████████████████████████████████████████ ██████████████████████████████████████████████████████████████ ██████████████████████████████████████████████████████████████ ██████████████████████████████████████████████████████████████ ██████████████████████████████████████████████████████████████ █████████████████████████████████████████. Auch in diesem Szenario war durch Dokumentation und Quellcode die Funktionalität nachvollziehbar.

2.2.4 Testanwendungen

Als weitere Prüfung habe ich █████████████████████ einen Funktionstest vorgenommen. Der Test ergab keine datenschutzrechtlichen Auffälligkeiten. Insbesondere endete die Überwachung zeitnah mit Wegfall der Netzwerkverbindung. Sowohl die gezeigte Protokollierung wie die Löschung der Software ███████████ █████████ verlief entsprechend den datenschutzrechtlichen Anforderungen.

Die TKÜ-Anlage selbst mache ich nicht zum Gegenstand der Kontrolle, die sich insoweit auf die Remote-Software und ihren Einsatz beschränkt. Ich weise in diesem Zusammenhang aber darauf hin, dass aufgezeichnete Gespräche auch teilweise gelöscht werden können müssen, sofern der Schutz des Kernbereichs privater Lebensgestaltung dies erfordert.

2.2.5 Echtbetrieb

██████████████████████████████████████████████████████████████ ██████████████████████████████████████████████████████████████ █████████████████████████████████████████

██████████████████████████████████████████████████████████████ ██████████████████████████████████████████████████████████████ ██████████████████████████████████████████████████████████████ ██████████████████████████████████████████████████████████████ ██████████████████████████████████████████████████████████████ ██████████████████████████████████████████████████████████████ ██████████████████████████████████████████████████████████████ ██████████████████████████████████████████████████

Mit freundlichen Grüßen

Ulrich Kelber